<html>
<head><meta charset="utf-8"><title>Accept `pc` in place of `unknown` and `un… compiler-team#441 · t-compiler/major changes · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/index.html">t-compiler/major changes</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html">Accept `pc` in place of `unknown` and `un… compiler-team#441</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="243265298"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243265298" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> triagebot <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243265298">(Jun 19 2021 at 19:32)</a>:</h4>
<p>A new proposal has been announced: <a href="https://github.com/rust-lang/compiler-team/issues/441">Accept <code>pc</code> in place of <code>unknown</code> and <code>unknown</code> in place of <code>pc</code> for <code>x86_64</code> and <code>i?86</code> targets #441</a>. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.</p>



<a name="243269470"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243269470" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243269470">(Jun 19 2021 at 21:15)</a>:</h4>
<p>fwiw, I really appreciate that rustc only uses a single canonical string for a target. Having aliases can cause confusion, and makes any tool that needs to deal with triples deal with the aliasing problems. For example, Cargo itself assumes there is a single triple, and its cfg matching wouldn't know about the aliases.</p>
<p>I'm a bit uncertain from the context of the proposal. It seems like there is a desire to try to match GNU-style triples with rustc-style triples. Is that what the script is trying to do? It seems like that is a much larger problem than just differences of pc and unknown. My understanding of <a href="https://github.com/gcc-mirror/gcc/blob/master/config.guess">config.guess</a> and GNU-style triples is that it supports a large number of heuristics for matching target triples, and those can be changed by distros to all sorts of different variants. I would be surprised if just pc and unknown would be sufficient to map the two in general.</p>



<a name="243270461"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243270461" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243270461">(Jun 19 2021 at 21:41)</a>:</h4>
<p>Cargo cfg matching uses <code>rustc --print cfg</code> so it would work fine with aliasing targets as soon as rustc supports it.</p>



<a name="243271824"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243271824" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243271824">(Jun 19 2021 at 22:17)</a>:</h4>
<p>Not for exact target name matches.  And same with any build script or anything else that inspects the target name.  (though I think that practice is flawed, and I'm disappointed that exact target name matching is going to be added to <code>cfg</code>).</p>



<a name="243271992"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243271992" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243271992">(Jun 19 2021 at 22:22)</a>:</h4>
<p>I would rather eliminate the <code>pc</code> and <code>unknown</code> tag altogether, and simply refer to Windows as e.g. <code>x86_64-windows-msvc</code></p>



<a name="243273354"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243273354" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243273354">(Jun 19 2021 at 22:58)</a>:</h4>
<blockquote>
<p>I'm a bit uncertain from the context of the proposal. It seems like there is a desire to try to match GNU-style triples with rustc-style triples. Is that what the script is trying to do? It seems like that is a much larger problem than just differences of pc and unknown. </p>
</blockquote>
<p>If you are referring to the script I linked in the issue, right now, yes, that's what it's doing. It attempts to fix the host target name to one acceptable to the rust compiler detected previously. Since it's using the value of $host from autotools (this is an m4 macro), it will be automatically detected (if not overridden at the --build or --host levels) which is where the issue is (though it's not apparent there, as host checking isn't performed if --host isn't specified). As a result, I use a serious of nested case and if blocks to attempt to find a correct variation that is accepted.<br>
The current issues I've noted are pc vs. unknown as well as the generalization of i?86 (rustc only accepts i586 and i686 for linux and windows. I believe there is at least one i486.)</p>
<p>I would note that the proposal is not to change the name of rustc's targets here, simply to accept these cases when passed explicitly to --target.</p>



<a name="243273426"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243273426" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243273426">(Jun 19 2021 at 23:00)</a>:</h4>
<blockquote>
<p>Not for exact target name matches.  And same with any build script or anything else that inspects the target name.  (though I think that practice is flawed, and I'm disappointed that exact target name matching is going to be added to <code>cfg</code>).</p>
</blockquote>
<p>Exact name matching can be useful (eg. invoking other toolchains), and in those cases you may <em>want</em> a particular form as the end user.</p>



<a name="243273781"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243273781" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243273781">(Jun 19 2021 at 23:10)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441/near/243271992">said</a>:</p>
<blockquote>
<p>I would rather eliminate the <code>pc</code> and <code>unknown</code> tag altogether, and simply refer to Windows as e.g. <code>x86_64-windows-msvc</code></p>
</blockquote>
<p>That would change the form of the target, though. While <code>pc</code> and <code>unknown</code> vendors are generally not distinct (for x86_64 and ix86), some are (for example, <code>x86_64-apple-darwin</code> is functionally distinct from <code>x86_64-unknown-darwin</code> or <code>x86_64-pc-darwin</code>)</p>



<a name="243276950"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243276950" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243276950">(Jun 20 2021 at 00:28)</a>:</h4>
<p>Sure, but we don't meaningfully support the distinction.</p>



<a name="243277229"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243277229" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243277229">(Jun 20 2021 at 00:35)</a>:</h4>
<p>If we decided to have an <code>unknown-darwin</code> target that is, say, PureDarwin on a possibly-non-Apple-provided PC, that's fine.<br>
My argument is simply that it functionally is just one token for us. Truncating unnecessary data from the token is fine.</p>



<a name="243280530"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243280530" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243280530">(Jun 20 2021 at 02:03)</a>:</h4>
<p>In any case, that would also operate counter to my proposal, which is intended to make it easier to use non-cargo tooling (such as autotools).</p>



<a name="243300015"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243300015" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243300015">(Jun 20 2021 at 12:03)</a>:</h4>
<p>Another reasonable use would be to nail down the semantics for non-rustc compilers.<br>
gcc-rs will likely support every gcc target reguardless, including target aliases. This may or may not be less of a concern, because gcc is a single-target toolchain, so it will never be able to compile for both <code>x86_64-pc-linux-gnu</code> and <code>x86_64-unknown-linux-gnu</code> (despite them otherwise being semantically identical). <br>
&lt;<a href="https://github.com/LightningCreations/lccc">https://github.com/LightningCreations/lccc</a>&gt;, being written by myself, also would differ in that the frontend, which  would query target properties via the middle architecture library <code>libxlang</code>, would never be able to observe the difference, unless it needed to access the exact target name for various reasons (such as setting implicit cfg flags, such as <code>target</code>). In xlang itself, <code>Target{Architecture::X86_64,Vendor::PC,OperatingSystem::Linux,Environment::GNU,BinaryFormat::None}</code> (is the canonical representation of <code>x86_64-pc-linux-gnu</code>) maps to the same <code>const TargetDescriptor*</code> as <code>Target{Architecture::X86_64,Vendor::Unknown,OperatingSystem::Linux,Environment::GNU,BinaryFormat::None}</code>. Thus, if there are issues with aliasing targets, my <em>strong</em> preference is that they be resolved.</p>



<a name="243303693"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243303693" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243303693">(Jun 20 2021 at 13:47)</a>:</h4>
<p>I mean I don’t think the <code>pc</code> variant doesn’t have to be a literal alias, you could have distinct <code>unknown</code> and <code>pc</code> target variants for platforms that are functionally the same, so to rustc they’re two separate targets, but behind the scenes they’re derived from the same target spec with the only difference being the vendor name, similar to the base targets we already have today.</p>
<p>That would fulfill the same goal of having compatibility with other tools.</p>



<a name="243315973"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243315973" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243315973">(Jun 20 2021 at 18:48)</a>:</h4>
<p>My understanding is our targets don't precisely match GCC's understanding of the targets, so that the apparent naming compatibility is somewhat misleading. Thus, I am in favor not of making them more alike but instead further differentiating them.</p>



<a name="243316341"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243316341" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243316341">(Jun 20 2021 at 18:58)</a>:</h4>
<p>e.g. I believe i686 is a Pentium Pro to GCC and a Pentium 4 to Rust.<br>
While this may seem somewhat orthogonal, if the goal of this is to provide seamless compatibility with GCC tooling, then we've already failed that.</p>



<a name="243317736"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243317736" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243317736">(Jun 20 2021 at 19:31)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441/near/243316341">said</a>:</p>
<blockquote>
<p>e.g. I believe i686 is a Pentium Pro to GCC and a Pentium 4 to Rust.<br>
While this may seem somewhat orthogonal, if the goal of this is to provide seamless compatibility with GCC tooling, then we've already failed that.</p>
</blockquote>
<p>Isn't this technically wrong on the part of rustc, though (may or may not be an issue)? The sixth generation x86, 80686 or i686, is the Pentium Pro (from intel, at least).  <a href="https://en.wikipedia.org/wiki/X86#Chronology">Wikipedia</a> seems to list Pentium 4 under "Enhanced Platform", not under 6th generation. That being said, I assume this is somewhat of a lesser issue, unless someone actually tries compiling for a Pentium Pro. I'm not looking for 100% seamless compatibility, just better compatibility with such tooling without absolute hacks being necessary, as well as compatibility with compilers that do use GNU-style tuples.</p>



<a name="243318476"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243318476" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243318476">(Jun 20 2021 at 19:49)</a>:</h4>
<blockquote>
<p>Isn't this technically wrong on the part of rustc</p>
</blockquote>
<p>Yes, rustc is wrong here, but I believe that part of the reason i686 and i586 are separated is so that i686 would allow access to the target features present on common 64bit-capable hardware (namely sse and sse2). If my understanding is correct, then doing the "correct" thing here would somewhat defeat the point of having these targets.</p>



<a name="243318564"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243318564" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243318564">(Jun 20 2021 at 19:51)</a>:</h4>
<p>That's probably also wrong, if the intent is to allow 32-bit programs on a 64-bit machine.</p>



<a name="243318803"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243318803" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243318803">(Jun 20 2021 at 19:57)</a>:</h4>
<p>Don't really need to look for 4D chess moves in all this. Targets grew in a very ad-hoc manner and in most cases making decisions about the targets went the way of "seemed reasonable to do it like this at the time". GNU toolchains made these arbitrary-ish decisions in somewhat a different direction. Where rust mostly worked backwards from "what would make sense for this target name _today_?", gnu toolchains mostly went "what the name should be for this new hardware?"</p>



<a name="243318856"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243318856" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243318856">(Jun 20 2021 at 19:58)</a>:</h4>
<p>Right.</p>



<a name="243318944"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243318944" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ray Redondo <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243318944">(Jun 20 2021 at 20:01)</a>:</h4>
<p>But at the same time, GNU made sure that many names that could make sense are treated as the correct names in the end. Rust makes no such attempt currently.</p>



<a name="243319007"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243319007" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243319007">(Jun 20 2021 at 20:02)</a>:</h4>
<p>Might not be too late. Just nobody cared about the naive implementation enough to work it to completion of some sort.</p>



<a name="243319101"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243319101" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243319101">(Jun 20 2021 at 20:05)</a>:</h4>
<p>In any case, my argument is that harmonizing the names with GCC re: <code>pc</code> and <code>unknown</code> without reconciling our differences in this regard is removing the appearance of a seam when there is very much a seam there. I have already had to be corrected on certain misunderstandings because I thought there was a direct parallel between Rust's tuples and the GNU build system's tuples. Providing more illusory seamlessness does not seem like a good time. I don't want others to have more opportunities to make my mistakes.</p>
<p>If the differences are reconciled... well, I do not know if adopting GNU's decisions wholesale is a good idea either. But I would obviously wholly retract my objection re: making convenient something that should be (slightly) inconvenient.</p>



<a name="243319342"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243319342" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243319342">(Jun 20 2021 at 20:10)</a>:</h4>
<p>Some newer targets like wasm32-wasi dropped the -unknown- part. If anything I would be in favor of renaming eg x86_64-unknown-linux-gnu to  x86_64-linux-gnu and making the former an alias to the later. That also more closely matches the target names debian uses. (It uses amd64 instead of x86_64 though I think.)</p>



<a name="243319438"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243319438" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ray Redondo <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243319438">(Jun 20 2021 at 20:13)</a>:</h4>
<p><code>pc</code> vs <code>unknown</code> seems to not actually be a difference on x86; it's just different defaults for that slot.</p>
<p>The field is just part of the standard target tuple format, and it was easier to keep it around with a placeholder value than eliminate it.</p>



<a name="243320410"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243320410" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243320410">(Jun 20 2021 at 20:38)</a>:</h4>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> <a href="#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441/near/243319342">said</a>:</p>
<blockquote>
<p>Some newer targets like wasm32-wasi dropped the -unknown- part. If anything I would be in favor of renaming eg x86_64-unknown-linux-gnu to  x86_64-linux-gnu and making the former an alias to the later. That also more closely matches the target names debian uses. (It uses amd64 instead of x86_64 though I think.)</p>
</blockquote>
<p>Well, <code>x86_64-linux-gnu</code> is also a useful target, but it's not a canonical target, at least as far as config.sub is concerned. In fact, <code>x86_64-linux-gnu</code> canonicalizes to <code>x86_64-pc-linux-gnu</code>. </p>
<p><span class="user-mention silent" data-user-id="396093">Ray Redondo</span> <a href="#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441/near/243319438">said</a>:</p>
<blockquote>
<p><code>pc</code> vs <code>unknown</code> seems to not actually be a difference on x86; it's just different defaults for that slot.</p>
<p>The field is just part of the standard target tuple format, and it was easier to keep it around with a placeholder value than eliminate it.</p>
</blockquote>
<p><code>pc</code> and <code>unknown</code> are indeed not functionally distinct on i?86 or x86_64. The slot was kept to keep a consistent canonical form, as there are some architectures (and some vendors) where the vendor field is menaingful. Having consistenly 3 parts (where the third can sometimes be further split), makes it easier to split, and to match individual components, especially in shell scripting. Having worked on <code>config.sub</code> and also <a href="https://crates.io/crates/target-tuples">https://crates.io/crates/target-tuples</a>, the consistent form of canonical targets is actually incredibly helpful (and working with non-canonical forms is also painful).</p>



<a name="243320808"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243320808" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243320808">(Jun 20 2021 at 20:49)</a>:</h4>
<p>In any case, based on further discussion on the IRLO thread (&lt;<a href="https://internals.rust-lang.org/t/expand-targets-acceptable-to-rustc/14885/16">https://internals.rust-lang.org/t/expand-targets-acceptable-to-rustc/14885/16</a>&gt;), I believe this is something that warrants an RFC. Am I correct in assuming that an MCP can move to an RFC after approval for t-compiler?</p>



<a name="243323034"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243323034" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243323034">(Jun 20 2021 at 21:41)</a>:</h4>
<p>...So, now that we have extended key-value attributes stabilized by <a href="https://github.com/rust-lang/rust/pull/83366">https://github.com/rust-lang/rust/pull/83366</a>, forgive me if I don't understand what it enables, but would it be possible to define a Target type with appropriate fields that allows (non-exhaustive, of course) pattern-matching on real types with real paths instead of strings? Forgive me if I don't understand.</p>
<p>There are many errors related to the "string typing" interfaces of current targets such that I believe moving away from it would be preferable, and I believe we'd actually have a much easier time <strong>defining</strong> aliases to those real types if we actually had them, as well.</p>



<a name="243323182"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243323182" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243323182">(Jun 20 2021 at 21:44)</a>:</h4>
<p>then "pc" and "unknown" becomes <code>Target { vendor: Unknown, .. }</code><br>
and then when we talk about making the strings aliases, we know what the real value that we're pointing to is.</p>



<a name="243323287"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243323287" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243323287">(Jun 20 2021 at 21:46)</a>:</h4>
<p>Sorry, I realize that this is getting a bit afield.</p>



<a name="243323302"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243323302" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243323302">(Jun 20 2021 at 21:47)</a>:</h4>
<p>I don't understand how key-value attributes are related.</p>



<a name="243323367"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243323367" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243323367">(Jun 20 2021 at 21:48)</a>:</h4>
<p>they look like <code>#[KEY = VALUE]</code>, where <code>VALUE</code> may include 0 or more macros as long as they expand to a literal</p>



<a name="243323622"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243323622" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243323622">(Jun 20 2021 at 21:55)</a>:</h4>
<p>the one used most often is <code>#[doc = include_str!("x.md")]</code></p>



<a name="243324241"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243324241" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243324241">(Jun 20 2021 at 22:11)</a>:</h4>
<p><del>The problem (or rather the good thing) with targets is that they are a map of string to target definition on the compiler side, rather than the language side.</del></p>
<p>Lets see if I can reword this to read right:</p>
<p>The good thing: the target string to target definition is entirely a compiler-side thing (that's good, it means we can change it)<br>
The bad thing: its a direct string -&gt; definition map, not something smarter (that's bad)</p>



<a name="243324249"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243324249" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243324249">(Jun 20 2021 at 22:11)</a>:</h4>
<p>Though <a href="https://github.com/rust-lang/rfcs/pull/2991">https://github.com/rust-lang/rfcs/pull/2991</a> is set to bake the target strings into the language too.</p>



<a name="243326159"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243326159" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243326159">(Jun 20 2021 at 23:04)</a>:</h4>
<p><span class="user-mention" data-user-id="123586">@nagisa</span> I’m not sure it’s correct to interpret <a href="https://github.com/rust-lang/rfcs/issues/2991">rfcs#2991</a> as baking the string values into the language, as that would be incompatible with the target tier policy. We have reserved the right to remove targets so it’s perfectly valid for <code>#[cfg(target = “arch-vendor-env”)]</code> to work in one release, never in the next release, and then work again in another release.</p>
<p>Additionally there are custom targets which get to set the names, so people are already using <code>cfg</code> with target components that aren’t available by default to the compiler.</p>



<a name="243326437"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243326437" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243326437">(Jun 20 2021 at 23:13)</a>:</h4>
<p>(Custom targets aren't stable, though, right? To some extent I guess that's <a href="https://github.com/rust-lang/rust/issues/71009">https://github.com/rust-lang/rust/issues/71009</a>...)</p>



<a name="243326702"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243326702" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243326702">(Jun 20 2021 at 23:21)</a>:</h4>
<p>I don't consider the target components to share the same issues for the purposes of this as they come from the target definition not the target string. Most notably target_arch will not always match the first component of the target triple and there isn't really a widespread expectation that it would.</p>



<a name="243326799"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243326799" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243326799">(Jun 20 2021 at 23:23)</a>:</h4>
<p>Target strings also aren't quite a combination of target arch/vendor/os/env though it might be interesting if they were canonically.</p>



<a name="243332384"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243332384" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243332384">(Jun 21 2021 at 01:57)</a>:</h4>
<p>Sure, I was just mostly trying to have a example, without getting caught up in the specifics of a real target.</p>



<a name="243332647"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243332647" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243332647">(Jun 21 2021 at 02:03)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span> Ah I didn’t know that was not intentional, the embedded WG use it in their guides, so I assumed it was intentional. Though the ship might have sailed in my opinion for disabling custom targets through JSON outright, because this is something being relied on in production situations. There are targets that simply can’t ever be put in rustc because they are proprietary and confidential to the point that you can’t contain any references unless it’s under NDA. These platforms need a custom target spec, and I feel like too many may already depend on it that if it was disabled, those users would just pin to the last version that accepted it.</p>



<a name="243332712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243332712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243332712">(Jun 21 2021 at 02:05)</a>:</h4>
<p>I think fully destabilizing is indeed likely not feasible, but identifying a stable subset might be more viable. The schema changes pretty regularly.</p>



<a name="243332787"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/233931-t-compiler/major%20changes/topic/Accept%20%60pc%60%20in%20place%20of%20%60unknown%60%20and%20%60un%E2%80%A6%20compiler-team%23441/near/243332787" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/233931-t-compiler/major-changes/topic/Accept.20.60pc.60.20in.20place.20of.20.60unknown.60.20and.20.60un.E2.80.A6.20compiler-team.23441.html#243332787">(Jun 21 2021 at 02:07)</a>:</h4>
<p>I think the schema being completely unstable is totally reasonable. In the situations where I’ve used custom targets we’re pinning to a version anyway and choose when to upgrade the compiler.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>